chore(SECURITY.md): add more description regarding the UDF security model#4299
chore(SECURITY.md): add more description regarding the UDF security model#4299bobbai00 wants to merge 9 commits intoapache:mainfrom
Conversation
…date - Add UDF security warning in UI Users section about unsandboxed code execution - Expand Computing Unit Types with detailed UDF access implications - Add Java to supported UDF languages throughout - Add "Isolation of application secrets" to NOT Guaranteed list - Expand User Code Execution section with known limitation details - Update Last Updated date to March 2026 https://claude.ai/code/session_01UnG9kQ8oHvtDXPMmouf7z5
- Restore Unicode right single quotation mark in Resources section - Revert Access Level wording to original phrasing - Restore trailing space in Deployments section line - Revert Last Updated date back to November 2025 All substantive UDF security content additions are preserved. https://claude.ai/code/session_01UnG9kQ8oHvtDXPMmouf7z5
Reverts the remaining change flagged in PR review comment on line 272. https://claude.ai/code/session_01UnG9kQ8oHvtDXPMmouf7z5
|
Sorry, but why is the change? it is not documented... and I don't know why we are changing it. If there are private context, please provide link in pr description so that ppl with access can read. |
The email thread is attached. Please review the changes introduced in this PR. Thanks. |
Yicong-Huang
left a comment
Yicong-Huang
left a comment
There was a problem hiding this comment.
Left comments in place. Otherwise, LGTM
- Update Last Updated date to March 2026 - Generalize JVM-specific references to runtime-agnostic language - Remove specific mentions of JWT secrets and database credentials https://claude.ai/code/session_01UnG9kQ8oHvtDXPMmouf7z5
|
I think the line Can we change it to |
Restructure all UDF-related sections to follow a consistent 3-point tone: 1. State that the security model defines distinct roles with different privileges 2. Acknowledge UDFs as a known limitation that can break role boundaries 3. State deployment managers' responsibility to mitigate via sandboxing, disallowing in-process (coordinator JVM) UDFs, and role restrictions https://claude.ai/code/session_01UnG9kQ8oHvtDXPMmouf7z5
|
There are too many duplications of the same statement. It's better not to use AI on this kind of document: let's make it less verbose and more concise. |
| Texera executes workflows on **computing units**. UI users (REGULAR and ADMIN) can execute arbitrary code (e.g., through | ||
| UDFs written in Python, R, Scala) within computing units as part of their workflows. This code is currently not | ||
| sandboxed or restricted by Texera. Deployment managers configure which types of computing units are available: | ||
| UDFs written in Python, R, Java, Scala) within computing units as part of their workflows. UDF execution is a known limitation that can break the intended privilege boundaries between roles — UDF code may access resources available in the execution environment, such as environment variables, configuration values, and other application state. Deployment managers are responsible for mitigating this risk by applying techniques such as sandboxing UDF execution, disallowing in-process (coordinator JVM) UDFs, and ensuring that only trusted users are granted roles that permit code execution. |
There was a problem hiding this comment.
replace in-process UDFs with Java UDFs. Remove the (coordinator JVM)
| - Network and firewall settings | ||
| - Container orchestration | ||
|
|
||
| **Important**: Texera's security model defines distinct roles with different privilege levels. However, REGULAR and ADMIN users can execute arbitrary code within computing units through User-Defined Functions (UDFs), which is a known limitation that can break the intended role boundaries. UDF code may access resources available in the execution environment, including environment variables, configuration values, and application state. Deployment managers are responsible for mitigating this by applying techniques such as sandboxing UDF execution and disallowing in-process (coordinator JVM) UDFs. See [Deployments and Computing Units](#deployments-and-computing-units) and [What is NOT a Security Issue](#what-is-not-a-security-issue) for more details. |
There was a problem hiding this comment.
replace in-process UDFs with Java UDFs. Remove the (coordinator JVM)
There was a problem hiding this comment.
Fix the what-is-not-a-security-issue link
5 participants
What changes were proposed in this PR?
Updated
SECURITY.mdto provide more detailed guidance on UDF (User-Defined Function) security implications:Any related issues, documentation, discussions?
Discussion: https://lists.apache.org/thread/thtr1817swnxb94z5fqwmkoob5yck4kl
How was this PR tested?
Documentation-only change. No code or tests affected.
Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (claude-opus-4-6)